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Abstract 


An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry 
ATM cells over an MPLS network. This enables service providers to 
offer "emulated" ATM services over existing MPLS networks. This 
document specifies methods for the encapsulation of ATM cells within 
a pseudowire. It also specifies the procedures for using a PW to 
provide an ATM service. 
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1. Introduction 


Packet Switched Networks (PSNs) have the potential to reduce the 
complexity of a service provider’s infrastructure by allowing 
virtually any existing digital service to be supported over a single 
networking infrastructure. The benefit of this model to a service 
provider is threefold: 


-i. Leveraging of the existing systems and services to provide 
increased capacity from a packet-switched core. 


-ii. Preserving existing network operational processes and 
procedures used to maintain the legacy services. 


-iii. Using the common packet-switched network infrastructure to 
support both the core capacity requirements of existing 
Services and the requirements of new services supported 
natively over the packet-switched network. 


This document describes a method to carry ATM services over MPLS. It 
lists ATM-specific requirements and provides encapsulation formats 
and semantics for connecting ATM edge networks through a packet- 
Switched network using MPLS. 


Figure 1, below, displays the ATM services reference model. This 
model is adapted from [RFC3985]. 


&K----- Pseudowire ----- > 


| |<-- PSN Tunnel -->| | 


ATM Service V V V V ATM Service 
+----+ +----+ 
+----+ | | PE1| | PE2| | +----+ 
SP ee ee SD EN A Pla etic ete RAR 
CE1 | | | | CE2 
| [-2-------- oL PWS oun wi edt | ---------- | 
e 04 d | ee o 
^ t----4 +----+ | A 
| Provider Edge 1 Provider Edge 2 
LO Emulated Service ---------------- > 
Customer Customer 
Edge 1 Edge 2 


Figure 1: ATM Service Reference Model 
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2s 


Specification of Requirements 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Applicability Statement 


The ATM over PW service is not intended to perfectly emulate a 
traditional ATM service, but it can be used for applications that 
need an ATM transport service. 


The following are notable differences between traditional ATM service 
and the protocol described in this document: 


- ATM cell ordering can be preserved using the OPTIONAL sequence 
field in the control word; however, implementations are not 
required to support this feature. The use of this feature may 
impact other ATM quality of service (QoS) commitments. 


- The QoS model for traditional ATM can be emulated. However, the 
detailed specification of ATM QoS emulation is outside the scope 
of this document. The emulation must be able to provide the 
required ATM QoS commitments for the end-user application. 


- The ATM flow control mechanisms are transparent to the MPLS 
network and cannot reflect the status of the MPLS network. 


- Control plane support for ATM SVCs, SVPs, SPVCs, and SPVPs is 
outside the scope of this document. 


Note that the encapsulations described in this specification are 
identical to those described in [Y.1411] and [Y.1412]. 


Terminology 
One-to-one mode: specifies an encapsulation method that maps one ATM 
Virtual Channel Connection (VCC) (or one ATM Virtual Path Connection 


(VPC)) to one pseudowire. 


N-to-one mode (N >= 1): specifies an encapsulation method that maps 
one or more ATM VCCs (or one or more ATM VPCs) to one pseudowire. 


Packet-Switched Network (PSN): an IP or MPLS network. 
Pseudowire Emulation Edge to Edge (PWE3): a mechanism that emulates 


the essential attributes of a service (such as a T1 leased line or 
Frame Relay) over a PSN. 


Martini, et al. Standards Track [Page 4] 


RFC 4717 Encapsulation for ATM over MPLS December 2006 


Customer Edge (CE): a device where one end of a service originates 
and/or terminates. The CE is not aware that it is using an emulated 
service rather than a native service. 


Provider Edge (PE): a device that provides PWE3 to a CE. 


Pseudowire (PW): a connection between two PEs carried over a PSN. 
The PE provides the adaptation between the CE and the PW. 


Pseudowire PDU: a PDU sent on the PW that contains all of the data 
and control information necessary to provide the desired service. 


PSN Tunnel: a tunnel inside which multiple PWs can be nested so that 
they are transparent to core PSN devices. 


PSN Bound: the traffic direction where information from a CE is 
adapted to a PW, and PW-PDUs are sent into the PSN. 


CE Bound: the traffic direction where PW-PDUs are received on a PW 
from the PSN, re-converted back in the emulated service, and sent out 


to a CE. 


Ingress: the point where the ATM service is encapsulated into a 
pseudowire PDU (ATM to PSN direction). 


Egress: the point where the ATM service is decapsulated from a 
pseudowire PDU (PSN to ATM direction). 


CTD: Cell Transfer Delay. 

MTU: Maximum Transmission Unit. 

SDU: Service Data Unit. 

OAM: Operations And Maintenance. 

PVC: Permanent Virtual Connection. An ATM connection that is 
provisioned via a network management interface. The connection is 


not signaled. 


VCC: Virtual Circuit Connection. An ATM connection that is switched 
based on the cell header’s VCI. 


VPC: Virtual Path Connection. An ATM connection that is switched 
based on the cell header’s VPI. 


Additional terminology relevant to pseudowires and Layer 2 Virtual 
Private Networking (L2VPN) in general may be found in [RFC4026]. 
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5. General Encapsulation Method 


This section describes the general encapsulation format for ATM over 
PSN pseudowires. 


0 1 2 3 
01234567890123456789012345678<9021 
——R—R—R—R—R—R——————.-—.-—t-—t-t-t-tk-k-k-k-k-—L-—R——R——L——— 
PSN Transport Header (As Required) 
———R—R—R—R———————.-—.-—t-—t-t-t-t-k-k-k-tk-t-k-t-—b—b—b-—b—— 
Pseudowire Header | 
—R——R—R—R—R—R—B————k—.—.-—.-—t-t-t-k-k-k-k-k-t-—R—R—R——B——— 
ATM Control Word | 
———R—R—R—R—R——————.-—.-—t-—t-t-t-k-k-k-tk-k-t-k-—b—R— B 
ATM Service Payload 
—R—R—R—R—R—R—R—B—————.-—.-—t-—t-t-t-k-k-k-k-tk-t-t-t-—b—b—b-b—— 


+— +—+—+—+ 


Figure 2: General format for ATM encapsulation over PSNs 


The PSN Transport Header depends on the particular tunneling 
technology in use. This header is used to transport the encapsulated 
ATM information through the packet-switched core. 


The Pseudowire Header identifies a particular ATM service on a 
tunnel. In case of MPLS, the pseudowire header is one or more MPLS 
labels at the bottom of the MPLS label stack. 


The ATM Control Word is inserted before the ATM service payload. It 
may contain a length and sequence number in addition to certain 
control bits needed to carry the service. 


5.1. The Control Word 


The Control Words defined in this section are based on the Generic PW 
MPLS Control Word as defined in [RFC4385]. They provide the ability 
to sequence individual frames on the PW, avoidance of equal-cost 
multiple-path load-balancing (ECMP) [RFC2992], and OAM mechanisms 
including VCCV [VCCV]. 


[RFC4385] states, "If a PW is sensitive to packet misordering and is 
being carried over an MPLS PSN that uses the contents of the MPLS 
payload to select the ECMP path, it MUST employ a mechanism which 
prevents packet misordering." This is necessary because ECMP 
implementations may examine the first nibble after the MPLS label 
stack to determine whether or not the labelled packet is IP. Thus, 
if the VPI of an ATM connection carried over the PW using N-to-one 
cell mode encapsulation, without a control word present, begins with 
0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This 
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could, depending on the configuration and topology of the MPLS 
network, lead to a situation where all packets for a given PW do not 
follow the same path. This may increase out-of-order frames on a 
given PW, or cause OAM packets to follow a different path than actual 
traffic (see section 4.4.3 on Frame Ordering). 


The features that the control word provides may not be needed for a 
given ATM PW. For example, ECMP may not be present or active on a 
given MPLS network, strict frame sequencing may not be required, etc. 
If this is the case, and the control word is not REQUIRED by the 
encapsulation mode for other functions (such as length or the 
transport of ATM protocol specific information), the control word 
provides little value and is therefore OPTIONAL. Early ATM PW 
implementations have been deployed that do not include a control word 
or the ability to process one if present. To aid in backwards 
compatibility, future implementations MUST be able to send and 
receive frames without a control word present. 


In all cases, the egress PE MUST be aware of whether the ingress PE 
will send a control word over a specific PW. This may be achieved by 
configuration of the PEs, or by signaling, as defined in [RFC4447]. 


If the pseudowire traverses a network link that requires a minimum 
frame size (Ethernet is a practical example), with a minimum frame 
size of 64 octets, then such links will apply padding to the 
pseudowire PDU to reach its minimum frame size. In this case, the 
control word must include a length field set to the PDU length. A 
mechanism is required for the egress PE to detect and remove such 
padding. 


5.1.1. The Generic Control Word 
This control word is used in the following encapsulation modes: 


— ATM One-to-one Cell Mode 
- AAL5 PDU Frame Mode 


The PWE3 control word document [RFC4385] provides the following 
structure for the generic control word: 


0 1 2 3 
01. 2 342520 348 (9.0 EJE AS At: EE ES AE OF 142: 3-0 5.65 8. 9.0. 
V—R—R—E--------—R—L-———---.-—.-—.-.—4——---—.-— 4-4 

[000 0| Specified by PW Encapsulation 
E 4-44 
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The detailed structure for the ATM One-to-one Cell Mode and for the 
AAL5 PDU Frame Mode is as follows: 


0 1 2 3 
Ord 2 O PS (9.0: 1:2 :3 545-5: O .9 OF S A 5. 6: 5.8, O 
V—R—R—R-R-—-—----R- RR A A O O O O A ——t---.-— 4-4 
|o 0 0 0| Resva | Sequence Number | ATM Specific | 
O 


In the above diagram, the first 4 bits MUST be set to 0 to indicate 
PW data. They MUST be ignored by the receiving PE. 


The next four bits are reserved and MUST be set to 0 upon 
transmission and ignored upon reception. 


The next 16 bits provide a sequence number that can be used to 
guarantee ordered packet delivery. The processing of the sequence 
number field is OPTIONAL. 


The sequence number space is a 16-bit, unsigned circular space. The 
sequence number value 0 is used to indicate that the sequence number 
check algorithm is not used. 


The last 8 bits provide space for carrying ATM-specific flags. These 
are defined in the protocol-specific details below. 


There is no requirement for a length field for the One-to-one Cell 
and PDU Frame modes because the PSN PDU is always greater than 64 
bytes; therefore, no padding is applied in Ethernet links in the PSN. 


5.1.2. The Preferred Control Word 
This control word is used in the following encapsulation modes: 


- ATM N-to-one Cell Mode 
- AAL5 SDU Frame Mode 


It is defined as follows: 


0 1 2 3 

0 1.2.3.4 56 789 012 34.567 89.01 2.345678 90 1 
—R———c—.—.——R-—R—R—R—R—R—R— BM BM —À———.-—.-.-t-t-t- 
lo 0 0 o| Flags |Res| Length | Sequence Number 
$ hh + dd dd de de dd dd dd q 4 4 4 4 4 + + + +++ ++ +++ 


In the above diagram, the first 4 bits MUST be set to 0 to indicate 
PW data. They MUST be ignored by the receiving PE. 


Martini, et al. Standards Track [Page 8] 


RFC 4717 Encapsulation for ATM over MPLS December 2006 


The next 4 bits provide space for carrying protocol-specific flags. 
These are defined in the protocol-specific details below. 


The next 6 bits provide a length field, which is used as follows: If 
the packet’s length (defined as the length of the layer 2 payload 
plus the length of the control word) is less than 64 bytes, the 
length field MUST be set to the packet’s length. Otherwise, the 
length field MUST be set to zero. The value of the length field, if 
non-zero, can be used to remove any padding. When the packet reaches 
the service provider’s egress router, it may be desirable to remove 
the padding before forwarding the packet. Note that the length field 
is not used in the N-to-one mode and MUST be set to 0. 


The last 16 bits provide a sequence number that can be used to 
guarantee ordered packet delivery. The processing of the sequence 
number field is OPTIONAL. 


The sequence number space is a 16-bit, unsigned circular space. The 
sequence number value 0 is used to indicate that the sequence number 
check algorithm is not used. 


5.1.3. Setting the Sequence Number Field in the Control Word 


This section applies to the sequence number field of both the Generic 
and Preferred Control Words. 


For a given emulated VC and a pair of routers PE1 and PE2, if PEl 
supports packet sequencing, then the sequencing procedures defined in 
[RFC4385] MUST be used. 


Packets that are received out of order MAY be dropped or reordered at 
the discretion of the receiver. 


A simple extension of the processing algorithm in [RFC4385] MAY be 
used to detect lost packets. 


If a PE router negotiated not to use receive sequence number 
processing, and it received a non-zero sequence number, then it 
SHOULD send a PW status message indicating a receive fault and 
disable the PW. 


5.2. MTU Requirements 


The network MUST be configured with an MTU that is sufficient to 
transport the largest encapsulation frames. If MPLS is used as the 
tunneling protocol, for example, this is likely to be 12 or more 
bytes greater than the largest frame size. Other tunneling protocols 
may have longer headers and require larger MTUs. If the ingress 
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router determines that an encapsulated layer 2 PDU exceeds the MTU of 
the tunnel through which it must be sent, the PDU MUST be dropped. 

If an egress router receives an encapsulated layer 2 PDU whose 
payload length (i.e., the length of the PDU itself without any of the 
encapsulation headers) exceeds the MTU of the destination layer 2 
interface, the PDU MUST be dropped. 


5.3. MPLS Shim S Bit Value 


The ingress label switching router (LSR), PE1, MUST set the S bit of 
the PW label to a value of 1 to denote that the VC label is at the 
bottom of the stack. For more information on setting the S Bit, see 
[RFC3032]. 


5.4. MPLS Shim TTL Values 


The setting of the TTL value in the PW label is application 
dependent. In any case, [RFC3032] TTL processing procedure, 
including handling of expired TTLs, MUST be followed. 


6. Encapsulation Mode Applicability 


This document defines two methods for encapsulation of ATM cells, 
namely, One-to-one mode and N-to-one mode. 


The N-to-one mode (N >= 1) specifies an encapsulation method that 
maps one or more ATM VCCs (or one or more ATM VPCs) to one 
pseudowire. This is the only REQUIRED mode. One format is used for 
both the VCC or VPC mapping to the tunnel. The 4-octet ATM header is 
unaltered in the encapsulation; thus, the VPI/VCI is always present. 
Cells from one or more VCCs (or one or more VPCs) may be 
concatenated. 


The One-to-one mode specifies an encapsulation method that maps one 
ATM VCC or one ATM VPC to one pseudowire. For VCCs, the VPI/VCI is 
not included. For VPCs, the VPI is not included. Cells from one VCC 
or one VPC may be concatenated. This mode is OPTIONAL. 


Furthermore, different OPTIONAL encapsulations are supported for ATM 
AAL5 transport: one for ATM AAL5 SDUs, and another for ATM AAL5 PDUs. 


Three deployment models are supported by the encapsulations described 
in this document: 


-i. Single ATM Connection: A PW carries the cells of only one 
ATM VCC or VPC. This supports both the transport of 
multiservice ATM and L2VPN service over a PSN for all AAL 
types. 
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-ii. Multiple ATM Connections: A PW carries the cells of multiple 
ATM VCCs and/or VPCs. This also supports both the transport 
of multiservice ATM and L2VPN service over a PSN for all AAL 
types. 


-iii. AAL5: A PW carries the AAL5 frames of only one ATM VCC. A 
large proportion of the data carried on ATM networks is 
frame based and therefore uses AAL5. The AAL5 mapping takes 
advantage of the delineation of higher-layer frames in the 
ATM layer to provide increased bandwidth efficiency compared 
with the basic cell mapping. The nature of the service, as 
defined by the ATM service category [TM4.0] or the ATM 
transfer capability [I.371], should be preserved. 


6.1. ATM N-to-One Cell Mode 


This encapsulation supports both the Single and Multiple ATM 
Connection deployment models. This encapsulation is REQUIRED. 


The encapsulation allows multiple VCCs/VPCs to be carried within a 


single pseudowire. However, a service provider may wish to provision 
a single VCC to a pseudowire in order to satisfy QoS or restoration 
requirements. 


The encapsulation also supports the binding of multiple VCCs/VPCs to 
a single pseudowire. This capability is useful in order to make more 
efficient use of the PW demultiplexing header space as well as to 
ease provisioning of the VCC/VPC services. 


In the simplest case, this encapsulation can be used to transmit a 
single ATM cell per PSN PDU. However, in order to provide better PSN 
bandwidth efficiency, several ATM cells may optionally be 
encapsulated in a single PSN PDU. This process is called cell 
concatenation. 


The encapsulation has the following attributes: 
-i. Supports all ATM Adaptation Layer Types. 
-ii. Non-terminating OAM/Admin cells are transported among the 
user cells in the same order as they are received. This 


requirement enables the use of various performance 
management and security applications. 
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In order to gain transport efficiency on the PSN, multiple 
cells may be encapsulated in a single PW PDU. This process 
is called cell concatenation. How many cells to insert or 
how long to wait for cell arrival before sending a PW PDU is 
an implementation decision. Cell concatenation adds latency 
and delay variation to a cell relay service. 


The CLP bit from each cell may be mapped to a corresponding 
marking on the PW PDU. This allows the drop precedence to 
be preserved across the PSN. 


If the Single ATM connection deployment model is used, then 
it is simpler to provide an ATM layer service. The nature 
of the service, as defined by the ATM service category 
[TM4.0] or ATM transfer capability [1.371], should be 
preserved. 


The limitations of the ATM N-to-one cell encapsulation are: 


-vi. 


-vii. 


-viii. 


-ix. 


Martini, 


et 


There is no currently defined method to translate the 
forward congestion indication (EFCI) to a corresponding 
function in the PSN. Nor is there a way to translate PSN 
congestion to the EFCI upon transmission by the egress PE. 


The ATM cell header checksum can detect a 2-bit error or 
detect and correct a single-bit error in the cell header. 
Analogous functionality does not exist in most PSNs. A 
single bit error in a PW PDU will most likely cause the 
packet to be dropped due to an L2 Frame Check Sequence (FCS) 
failure. 


Cells can be concatenated from multiple VCCs or VPCs 
belonging to different service categories and QoS 
requirements. In this case, the PSN packet must receive 
treatment by the PSN to support the highest QoS of the ATM 
VCCs/VPCs carried. 


Cell encapsulation only supports point-to-point Label 
Switched Paths (LSPs). Multipoint-to-point and point-to- 
multi-point are for further study (FFS). 


The number of concatenated ATM cells is limited by the MTU 
Size and the cell transfer delay (CTD) and cell delay 
variation (CDV) objectives of multiple ATM connections that 
are multiplexed into a single PW. 
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6.2. ATM One-to-One Cell Encapsulation 


This OPTIONAL encapsulation supports the Single ATM Connection 
deployment model. 


Like the N-to-one cell encapsulation mode, the One-to-one mode 
supports cell concatenation. The advantage of this encapsulation is 
that it utilizes less bandwidth that the N-to-one encapsulation, for 
a given number of concatenated cells. Since only one ATM VCC or VPC 
is carried on a PW, the VCI and/or VPI of the ATM VCC or VPC can be 
derived from the context of the PW using the PW label. These fields 
therefore do not need to be encapsulated for a VCC, and only the VCI 
needs to be encapsulated for a VPC. This encapsulation thus allows 
service providers to achieve a higher bandwidth efficiency on PSN 
links than the N-to-one encapsulation for a given number of 
concatenated cells. 


The limitations vi, vii, ix, and x of N-to-one mode apply. 
6.3. AAL5 SDU Frame Encapsulation 


This OPTIONAL encapsulation supports the AAL5 model. This mode 
allows the transport of ATM AAL5 CSPS-SDUs traveling on a particular 
ATM PVC across the network to another ATM PVC. This encapsulation is 
used by a PW of type 0x0002 "ATM AAL5 SDU VCC transport" as allocated 
in [RFC4446]. 


The AAL5 SDU encapsulation is more efficient for small AAL5 SDUs than 
the VCC cell encapsulations. In turn, it presents a more efficient 
alternative to the cell relay service when carrying [RFC2684]- 
encapsulated IP PDUs across a PSN. 


The AAL5-SDU encapsulation requires Segmentation and Reassembly (SAR) 
on the PE-CE ATM interface. This SAR function is provided by common 
off-the-shelf hardware components. Once reassembled, the AAL5-SDU is 
carried via a pseudowire to the egress PE. Herein lies another 
advantage of the AAL5-SDU encapsulation. 


The limitations of the AAL5 SDU encapsulation are: 


-i. If an ATM OAM cell is received at the ingress PE, it is sent 
before the cells of the surrounding AAL5 frame. Therefore, 
OAM cell reordering may occur, which may cause certain ATM 
OAM performance monitoring and ATM security applications to 
operate incorrectly. 
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-ii. If the ALL5 PDU is scrambled using ATM security standards, a 
PE will not be able to extract the ALL5 SDU, and therefore 
the whole PDU will be dropped. 


-iii. The AAL5 PDU CRC is not transported across the PSN. The CRC 
must therefore be regenerated at the egress PE since the CRC 
has end-to-end significance in ATM security. This means 
that the AAL5 CRC may not be used to accurately check for 
errors on the end-to-end ATM VCC. 


-iv. The Length of AAL5 frame may exceed the MTU of the PSN. 
This requires fragmentation, which may not be available to 
all nodes at the PW endpoint. 


-v. This mode does not preserve the value of the CLP bit for 
every ATM cell within an AAL5 PDU. Therefore, transparency 
of the CLP setting may be violated. Additionally, tagging 
of some cells may occur when tagging is not allowed by the 
conformance definition [TM4.0]. 


-vi. This mode does not preserve the EFCI state for every ATM 
cell within an AAL5 PDU. Therefore, transparency of the 
EFCI state may be violated. 


6.4.  AAL5 PDU Frame Encapsulation 
This OPTIONAL encapsulation supports the AAL5 model. 


The primary application supported by AAL5 PDU frame encapsulation 
over PSN is the transparent carriage of ATM layer services that use 
AAL5 to carry higher-layer frames. The main advantage of this AAL5 
mode is that it is transparent to ATM OAM and ATM security 
applications. 


One important consideration is to allow OAM information to be treated 
as in the original network. This encapsulation mode allows this 
transparency while performing AAL5 frame encapsulation. This mode 
supports fragmentation, which may be performed in order to maintain 
the position of the OAM cells with respect to the user cells. 


Fragmentation may also be performed to maintain the size of the 
packet carrying the AAL5 PDU within the MTU of the link. 
Fragmentation provides a means for the PE to set the size of the PW 
packet to a different value than that of the original AAL5 PDU. This 
means that the PE has control on the delay and jitter provided to the 
ATM cells. 
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7. 


7. 


The whole AAL5-PDU is encapsulated. In this case, all necessary 
parameters, such as CPCS-UU (CPCS User-to-User indicator), CPI 
(Common Part Indicator), Length (Length of the CPCS-SDU) and CRC 
(Cyclic Redundancy Check), are transported as part of the payload. 
Note that carrying of the full PDU also allows the simplification of 
the fragmentation operation since it is performed at cell boundaries 
and the CRC in the trailer of the AAL5 PDU can be used to check the 
integrity of the PDU. 


Reassembly is not required at the egress PE for the PSN-to-ATM 
direction. 


The limitations v and vi of the AAL5 SDU mode apply to this mode as 
well. 


ATM OAM Cell Support 
1. VCC Case 


In general, when configured for ATM VCC service, both PEs SHOULD act 
as a VC switch, in accordance with the OAM procedures defined in 
[I.610]. 


The PEs SHOULD be able to pass the following OAM cells transparently: 


- F5 Alarm Indication Signal (AIS) (segment and end-to-end) 
- F5 Remote Defect Indicator (RDI) (segment and end-to-end) 
- F5 loopback (segment and end-to-end) 

- Resource Management 

- Performance Management 

- Continuity Check 

- Security 


However, if configured to be an administrative segment boundary, the 
PE SHOULD terminate and process F5 segment OAM cells. 


F4 OAM cells are inserted or extracted at the VP link termination. 
These OAM cells are not seen at the VC link termination and are 
therefore not sent across the PSN. 


When the PE is operating in AAL5 CPCS-SDU transport mode if it does 
not support transport of ATM cells, the PE MUST discard incoming MPLS 
frames on an ATM PW that contain a PW label with the T bit set. 
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7.2. VPC Case 


When configured for a VPC cell relay service, both PEs SHOULD act as 
a VP cross-connect in accordance with the OAM procedures defined in 
[1.610]. 


The PEs SHOULD be able to process and pass the following OAM cells 
transparently according to [1.610]: 


- F4 AIS (segment and end-to-end) 
- FA RDI (segment and end-to-end) 
- F4 loopback (segment and end-to-end) 


However, if configured to be an administrative segment boundary, the 
PE SHOULD terminate and process F4 segment OAM cells. 


F5 OAM are not inserted or extracted here. The PEs MUST be able to 
pass the following OAM cells transparently: 


- F5 AIS (segment and end-to-end) 

- F5 RDI (segment and end-to-end) 

- F5 loopback (segment and end-to-end) 
- Resource Management 

- Performance Management 

- Continuity Check 

- Security 


The OAM cell MAY be encapsulated together with other user data cells 
if multiple cell encapsulation is used. 


7.3. | SDU/PDU OAM Cell Emulation Mode 
A PE operating in ATM SDU or PDU transport mode that does not support 
transport of OAM cells across a PW MAY provide OAM support on ATM 


PVCs using the following procedures: 


- Loopback cells response 


If an F5 end-to-end OAM cell is received from an ATM VC, by 
either PE that is transporting this ATM VC, with a loopback 
indication value of 1, and the PE has a label mapping for the ATM 
VC, then the PE MUST decrement the loopback indication value and 
loop back the cell on the ATM VC. Otherwise, the loopback cell 
MUST be discarded by the PE. 
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- AIS alarm 


If an ingress PE, PEl, receives an AIS F4/F5 OAM cell, it MUST 
notify the remote PE of the failure. The remote PE, PE2, MUST in 
turn send F5 OAM AIS cells on the respective PVCs. Note that if 
the PE supports forwarding of OAM cells, then the received OAM 
AIS alarm cells MUST be forwarded along the PW as well. 


- Interface failure 


If the PE detects a physical interface failure, or the interface 
is administratively disabled, the PE MUST notify the remote PE 
for all VCs associated with the failure. 


—- PSN/PW failure detection 


If the PE detects a failure in the PW, by receiving a label 
withdraw for a specific PW ID, or the targeted Label Distribution 
Protocol (LDP) session fails, or a PW status TLV notification is 
received, then a proper AIS F5 OAM cell MUST be generated for all 
the affected ATM PVCs. The AIS OAM alarm will be generated on 
the ATM output port of the PE that detected the failure. 


7.4. Defect Handling 


Figure 3 illustrates four possible locations for defects on the PWE3 


service: 
— (a) On the ATM connection from CE to PE 
- (b) On the ATM side of the PW 
— (c) On the PSN side of the PE 
— (d) In the PSN 
+----+ +----+ 
+----+ | PE1| | PE2| 4----4 
| | ---a------ [Besa 121), A aren ea | ---------- | | 
| CE1| | | | | |CE2 | 
| | ---------- Peres ee wet a BW2S suse te ea Sek |---------- | | 
thenni | | | | 4----—4 
A +----+ +----+ ^ 
| Provider Edge 1 Provider Edge 2 
| 
| <-------------- Emúlated Service -------—-—------2-- > | 
Customer Customer 
Edge 1 Edge 2 


Figure 3: Defect Locations 
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For failures at (a) or (b), in the VPC case, the ingress PE MUST be 
able to generate an F4 AIS upon reception of a lower-layer defect 


(such as LOS). In the VCC case, the ingress PE SHOULD be able to 
generate an F5 AIS upon reception of a corresponding F4 AIS or 
lower-layer defect (such as LOS). These messages are sent across the 
PSN. 


For failures at (c) or (d), in the VCC case, the egress PE SHOULD be 
able to generate an F5 AIS based on a PSN failure (such as a PSN 
tunnel failure or LOS on the PSN port). In the VPC case, the egress 
PE SHOULD be able to generate an F4 AIS based on a PSN failure (such 
as a PSN tunnel failure or LOS on the PSN port). 


If the ingress PE cannot support the generation of OAM cells, it MAY 
notify the egress PE using a pseudowire-specific maintenance 
mechanism such as the PW status message defined in [RFC4447]. 
Alternatively, for example, the ingress PE MAY withdraw the 
pseudowire (PW label) label associated with the service. Upon 
receiving such a notification, the egress PE SHOULD generate the 
appropriate F4 AIS (for VPC) or F5 AIS (for VCC). 


If the PW in one direction fails, then the complete bidirectional 
service is considered to have failed. 


8. ATM N-to-One Cell Mode 


The N-to-one mode (N >= 1) described in this document allows a 
Service provider to offer an ATM PVC- or SVC-based service across a 
network. The encapsulation allows multiple ATM VCCs or VPCs to be 
carried within a single PSN tunnel. A service provider may also use 
N-to-one mode to provision either one VCC or one VPC on a tunnel. 
This section defines the VCC and VPC cell relay services over a PSN 
and their applicability. 
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8.1. ATM N-to-One Service Encapsulation 


This section describes the general encapsulation format for ATM over 
PSN pseudowires. 


0 1 2 3 
0123456789 0123456789012345678901 
d+ A O A A O A A O O O O o O o o + + + + 

| PSN Transport Header (As Required) 

++ A A O O O O O A O O o O o o o o o o + + + 
| pseudowire Header | 
++ A A O O O O A A O O o O o o o o o + + + 
|o 0 0 o| Flags |Res| Length | Sequence Number 

++ A A O O O O O O O O o o O o O o o + + + + 
| ATM Service Payload 
C E 


Figure 4: General format for ATM encapsulation over PSNs 


The PSN Transport Header depends on the particular tunneling 
technology in use. This header is used to transport the encapsulated 
ATM information through the packet-switched core. 


The Pseudowire Header identifies a particular ATM service on a 
tunnel.  Non-ATM services may also be carried on the PSN tunnel. 


As shown above, in Figure 4, the ATM Control Word is inserted before 
the ATM service payload. It may contain a length field and a 
sequence number field in addition to certain control bits needed to 
carry the service. 


The ATM Service Payload is specific to the service being offered via 
the pseudowire. It is defined in the following sections. 


In this encapsulation mode, ATM cells are transported individually. 
The encapsulation of a single ATM cell is the only REQUIRED 
encapsulation for ATM. The encapsulation of more than one ATM cell 
in a PSN frame is OPTIONAL. 


The ATM cell encapsulation consists of an OPTIONAL control word and 
one or more ATM cells, each consisting of a 4-byte ATM cell header 
and the 48-byte ATM cell payload. This ATM cell header is defined as 
in the FAST encapsulation [FBATM] section 3.1.1, but without the 
trailer byte. The length of each frame, without the encapsulation 
headers, is a multiple of 52 bytes. The maximum number of ATM cells 
that can be fitted in a frame, in this fashion, is limited only by 
the network MTU and by the ability of the egress router to process 
them. The ingress router MUST NOT send more cells than the egress 
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router is willing to receive. The number of cells that the egress 
router is willing to receive may either be configured in the ingress 
router or be signaled, for example using the methods described later 
in this document and in [RFC4447]. The number of cells encapsulated 
in a particular frame can be inferred by the frame length. The 
control word is OPTIONAL. If the control word is used, then the flag 
and length bits in the control word are not used. These bits MUST be 
set to 0 when transmitting, and MUST be ignored upon receipt. 


The EFCI and CLP bits are carried across the network in the ATM cell 
header. The edge routers that implement this document MAY, when 
either adding or removing the encapsulation described herein, change 
the EFCI bit from zero to one in order to reflect congestion in the 
network that is known to the edge router, and change the CLP bit from 
zero to one in order to reflect marking from edge policing of the ATM 
Sustained Cell Rate. The EFCI and CLP bits SHOULD NOT be changed 
from one to zero. 


This diagram illustrates an encapsulation of two ATM cells: 


0 1 2 3 
0123456789 0123456789012345678901 
E — —  — —— 

| Control word ( Optional ) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| VPI | VCI PTI |c] 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
ATM Payload ( 48 bytes ) 


| 
" 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- "M 
VPI | VCI PTI |c] 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
ATM Payload ( 48 bytes ) 


+ 


Y ———— + — + —— 
+ 


| 
| 
| 
" | 
ds ds da E da ds ds a tae tate da da EA tata ds do da a ds ds da da do da sd aE a A E 


Figure 5: Multiple Cell ATM Encapsulation 


* When multiple VCCs or VPCs are transported in one pseudowire, 
VPI/VCI values MUST be unique. When the multiple VCCs or VPCs 
are from different a physical transmission path, it may be 
necessary to assign unique VPI/VCI values to the ATM connections. 
If they are from the same physical transmission path, the VPI/VCI 
values are unique. 
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* VPI 


The ingress router MUST copy the VPI field from the incoming cell 
into this field. For particular emulated VCs, the egress router 
MAY generate a new VPI and ignore the VPI contained in this 
field. 


* VCI 


The ingress router MUST copy the VCI field from the incoming ATM 
cell header into this field. For particular emulated VCs, the 
egress router MAY generate a new VCI. 


* PTI & CLP (C bit) 


The PTI and CLP fields are the PTI and CLP fields of the incoming 
ATM cells. The cell headers of the cells within the packet are 
the ATM headers (without Header Error Check (HEC) field) of the 
incoming cell. 


9. ATM One-to-One Cell Mode 


The One-to-one mode described in this document allows a service 
provider to offer an ATM PVC- or SVC-based service across a network. 
The encapsulation allows one ATM VCC or VPC to be carried within a 
single pseudowire. 


9.1. ATM One-to-One Service Encapsulation 


This section describes the general encapsulation format for ATM over 
pseudowires on an MPLS PSN. Figure 6 provides a general format for 
encapsulation of ATM cells into packets. 


0 1 2 3 

0 L.2-3 4 5.6 7.8.9.0 1 2.3.4 5.6.7.8 9.01.2 34 56 7.8.9.0 1 
C — + + 
| PSN Transport Header (As Required) 
++ A A O O O O O A O O o O o o o o o o + + + 
| Pseudowire Header | 
++ A A O O A O O A O O O o o o o o ++ + 
|o 0 0 0| Resvd | Optional Sequence Number ATM Specific | 
d+ O A O O O O O A o o O o o o o o o + + + 
| ATM Service Payload 


+-4+-4+-4+-4+-4-4-4-4-4-4-4-4+-4-4+-4+-4+-4+-4+-4+-4-4+-4-4+-4-4-4-4-4-4-4-4-4 


Figure 6: General format for One-to-one mode encapsulation over PSNs 
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9 


95 


zs 


35 


The MPLS PSN Transport Header depends on how the MPLS network is 
configured. The Pseudowire Header identifies a particular ATM 
service within the PSN tunnel created by the PSN Transport Header. 


This header is used to transport the encapsulated ATM information 
through the packet-switched core. 


The generic control word is inserted after the Pseudowire Header. 
The presence of the control word is REQUIRED. 


The ATM Specific Header is inserted before the ATM service payload. 
The ATM Specific Header contains control bits needed to carry the 
service. These are defined in the ATM service descriptions below. 
The length of ATM Specific Header may not always be one octet. It 
depends on the service type. 


The ATM payload octet group is the payload of the service that is 
being encapsulated. 


Sequence Number 

The sequence number is not required for all services. 

Treatment of the sequence number is according to section 5.1.3. 

ATM VCC Cell Transport Service 

The VCC cell transport service is characterized by the mapping of a 
single ATM VCC (VPI/VCI) to a pseudowire. This service is fully 
transparent to the ATM Adaptation Layer. The VCC single cell 
transport service is OPTIONAL. This service MUST use the following 


encapsulation format: 


0 1 2 3 
0 :2..3.4.5..6. 7.8.9 0 1.2.3 4 5-6 17: 8-9.0 L2 32.4 5» 6 7.8.9 0-1 


YH A A A A O O O O A O A O A O A O A O O O O O A O x4 
| PSN Transport Header (As Required) 

YH A A A A O O O O A O A O A O A O A O A O O O O A O A o + 
| Pseudowire Header | 
E 4-4 
|0 0 0 O| Resvd | Optional Sequence Number |M|v|Res| PTI |c| 
YH A A A A O O O O A O O O A O A O O O A O L—-——----.-- 
| | 


| ATM Cell Payload ( 48 bytes ) 


+-4+-4-4-4-4-4-4-4+-4+-4-4+-4-4-4+-4+-4-4-4-4+-4+-4+-4+-4-4-4-4+-4-4-4-4-4-4 


Figure 7: Single ATM VCC Cell Encapsulation 
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* M (transport mode) bit 


Bit (M) of the control byte indicates whether the packet contains 
an ATM cell or a frame payload. If set to 0, the packet contains 
an ATM cell. If set to 1, the PDU contains an AAL5 payload. 


* V (VCI present) bit 


Bit (V) of the control byte indicates whether the VCI field is 
present in the packet. If set to 1, the VCI field is present for 
the cell. If set to 0, no VCI field is present. In the case of 
a VCC, the VCI field is not required. For VPC, the VCI field is 
required and is transmitted with each cell. 


* Reserved bits 


The reserved bits should be set to 0 at the transmitter and 
ignored upon reception. 


* PTI Bits 


The 3-bit Payload Type Identifier (PTI) incorporates ATM Layer 
PTI coding of the cell. These bits are set to the value of the 
PTI of the encapsulated ATM cell. 


* C (CLP) Bit 


The Cell Loss Priority (CLP) field indicates CLP value of the 
encapsulated cell. 


For increased transport efficiency, the ingress PE SHOULD be able to 
encapsulate multiple ATM cells into a pseudowire PDU. The ingress 
and egress PE MUST agree to a maximum number of cells in a single 
pseudowire PDU. This agreement may be accomplished via a 
pseudowire-specific signaling mechanism or via static configuration. 


When multiple cells are encapsulated in the same PSN packet, the 
ATM-specific byte MUST be repeated for each cell. This means that 49 
bytes are used to encapsulate each 53 byte ATM cell. 
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0 1 2 3 
0:1.2.34 5.67 8 9 0.1.2 3.4 5.6 7.8 9 01.223 45 67 8 9.0 1 
YH A A O AO O O O O A O A O A O A O A O A O —-——-—---- 

| PSN Transport Header (As Required) 
YH A A A A O O O A O A O A O AO O A O O O O —-—-4--4- 
| Pseudowire Header | 
YH A A A A O O O O A O A O A O A A O A O L—-——---4-.-- 
lo 0 0 O| Resvd | Optional Sequence Number |M|v|Res| PTI |c| 
E 
| 
ATM Cell Payload ( 48 bytes ) | 
PEUT 
| 
| 


+— + 
Q 
+—+ 


ATM Cell Payload ( 48 bytes ) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+ 


+ —— 


Figure 8: Multiple ATM VCC Cell Encapsulation 
9.4. ATM VPC Services 


The VPC service is defined by mapping a single VPC (VPI) to a 
pseudowire. As such, it emulates a Virtual Path cross-connect across 
the PSN. All VCCs belonging to the VPC are carried transparently by 
the VPC service. 


The egress PE may choose to apply a different VPI other than the one 
that arrived at the ingress PE. The egress PE MUST choose the 
outgoing VPI based solely upon the pseudowire header. As a VPC 
service, the egress PE MUST NOT change the VCI field. 
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9.4.1. ATM VPC Cell Transport Services 
The ATM VPC cell transport service is OPTIONAL. 
This service MUST use the following cell mode encapsulation: 


0 1 2 3 

0 1. 2:34 5.658 9/0 Ae 2.34 5.6 1087 9:01: 2:34 ».6 1.8090: 1 
Foti t itt titi e — — — — + ++ 
| PSN Transport Header (As Required) 
C! — o —— o o + ++ 
| Pseudowire Header | 
E —  — — — 


|0 0 0 O| Resvd | Optional Sequence Number |M|v|Res| PTI |c| 
FTT RMR RR BRE RR] 
| VCI | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


ATM Cell Payload ( 48 bytes ) 


| 

| 

| 

| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 9: Single Cell VPC Encapsulation 


The ATM control byte contains the same information as in the VCC 
encapsulation except for the VCI field. 


* VCI Bits 


The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM 
Layer VCI value of the cell. 


For increased transport efficiency, the ingress PE SHOULD be able to 
encapsulate multiple ATM cells into a pseudowire PDU. The ingress 
and egress PE MUST agree to a maximum number of cells in a single 
pseudowire PDU. This agreement may be accomplished via a 
pseudowire-specific signaling mechanism or via static configuration. 


If the Egress PE supports cell concatenation, the ingress PE MUST 
only concatenate cells up to the "Maximum Number of concatenated ATM 
cells in a frame" interface parameter sub-TLV as received as part of 
the control protocol [RFC4447]. 


When multiple ATM cells are encapsulated in the same PSN packet, the 


ATM-specific byte MUST be repeated for each cell. This means that 51 
bytes are used to encapsulate each 53-byte ATM cell. 
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0 1 2 3 
0:1.2.34 5.67 8 9 0.1.2 3.4 5.6 7.8 9 01.223 45 67 8 9.0 1 
Poti o ——— A —— 2 

| PSN Transport Header (As Required) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Pseudowire Header | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|o 0 0 O| Resva | Optional Sequence Number |M|v|Res| PTI |c] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
VCI | | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 
ATM Cell Payload (48 bytes) | 
AA! 
|M|v|Res| PTI |c] VCI | 
—————————————— oo + 
VCI 
-+-+-+-+-+-+-+-+ 


—— + — + ——— + — 


| 
ATM Cell Payload (48 bytes) | 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+ 
Figure 10: Multiple Cell VPC Encapsulation 
10. ATM AAL5 CPCS-SDU Mode 


The AAL5 payload VCC service defines a mapping between the payload of 
an AAL5 VCC and a single pseudowire. The AAL5 payload VCC service 
requires ATM segmentation and reassembly support on the PE. 


The AAL5 payload CPCS-SDU service is OPTIONAL. 


Even the smallest TCP packet requires two ATM cells when sent over 
AAL5 on a native ATM device. It is desirable to avoid this padding 
on the pseudowire. Therefore, once the ingress PE reassembles the 
AAL5 CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer, and then 
the ingress PE inserts the resulting payload into a pseudowire PDU. 


The egress PE MUST regenerate the PAD and trailer before transmitting 
the AAL5 frame on the egress ATM port. 


This service does allow the transport of OAM and RM cells, but it 
does not attempt to maintain the relative order of these cells with 
respect to the cells that comprise the AAL5 CPCS-PDU. All OAM cells, 
regardless of their type, that arrive during the reassembly of a 
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10. 


single AAL5 CPCS-PDU are sent immediately on the pseudowire using 
N-to-one cell encapsulation, followed by the AAL5 payload. 
Therefore, the AAL5 payload VCC service will not be suitable for ATM 
applications that require strict ordering of OAM cells (such as 
performance monitoring and security applications). 


1. Transparent AAL5 SDU Frame Encapsulation 
The AAL5 CPCS-SDU is prepended by the following header: 


0 1 2 3 
012345678901234567890123456789 01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Res |r|E|c|u|Res| Length | Sequence Number (Optional) | 
d+ toto tata toto tanta $ — + q 4 + ++ + BÀ +++ +++ 
" 
ATM cell or AAL5 CPCS-SDU 
| à | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 11: AAL5 CPCS-SDU Encapsulation 


The AAL5 payload service encapsulation requires the ATM control word. 
The Flag bits are described below. 


* Res (Reserved) 


These bits are reserved and MUST be set to 0 upon transmission 
and ignored upon reception. 


* T (transport type) bit 


Bit (T) of the control word indicates whether the packet contains 
an ATM admin cell or an AAL5 payload. If T = 1, the packet 
contains an ATM admin cell, encapsulated according to the N-to- 
one cell relay encapsulation, Figure 4. If not set, the PDU 
contains an AAL5 payload. The ability to transport an ATM cell 
in the AAL5 SDU mode is intended to provide a means of enabling 
administrative functionality over the AAL5 VCC (though it does 
not endeavor to preserve user-cell and admin-cell 
arrival/transport ordering). 


* E (EFCI) Bit 


The ingress router, PE1, SHOULD set this bit to 1 if the EFCI bit 
of the final cell of those that transported the AAL5 CPCS-SDU is 
set to 1, or if the EFCI bit of the single ATM cell to be 
transported in the packet is set to 1. Otherwise, this bit 
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Iis 


Ti. 


SHOULD be set to 0. The egress router, PE2, SHOULD set the EFCI 
bit of all cells that transport the AAL5 CPCS-SDU to the value 
contained in this field. 


* C (CLP) Bit 


The ingress router, PE1, SHOULD set this bit to 1 if the CLP bit 
of any of the ATM cells that transported the AAL5 CPCS-SDU is set 
to 1, or if the CLP bit of the single ATM cell to be transported 
in the packet is set to 1. Otherwise this bit SHOULD be set to 
0. The egress router, PE2, SHOULD set the CLP bit of all cells 
that transport the AAL5 CPCS-SDU to the value contained in this 
field. 


* U (Command/Response Field) Bit 


When FRF.8.1 Frame Relay/ATM PVC Service Interworking [RFC3916] 
traffic is being transported, the CPCS-UU Least Significant Bit 
(LSB) of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit. 
The ingress router, PE1, SHOULD copy this bit to the U bit of the 
control word. The egress router, PE2, SHOULD copy the U bit to 
the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS PDU. 


AAL5 PDU Frame Mode 


The AAL5 payload PDU service is OPTIONAL. 


1. Transparent AAL5 PDU Frame Encapsulation 


In this mode, the ingress PE encapsulates the entire CPCS-PDU 
including the PAD and trailer. 


This mode MAY support fragmentation procedures described in the 
"Fragmentation" section below, in order to maintain OAM cell 
sequencing. 


Like the ATM AAL5 payload VCC service, the AAL5 transparent VCC 
service is intended to be more efficient than the VCC cell transport 
service. However, the AAL5 transparent VCC service carries the 
entire AAL5 CPCS-PDU, including the PAD and trailer. Note that the 
AAL5 CPCS-PDU is not processed, i.e., an AAL5 frame with an invalid 
CRC or length field will be transported. One reason for this is that 
there may be a security agent that has scrambled the ATM cell 
payloads that form the AAL5 CPCS-PDU. 


This service supports all OAM cell flows by using a fragmentation 
procedure that ensures that OAM cells are not repositioned in respect 
to AAL5 composite cells. 
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The M, V, Res, 


and C bits are as defined earlier for VCC One-to-one 


cell mode. 


Martini, 


YU Bit 


This field indicates whether this frame contains the last cell of 
an AAL5 PDU and represents the value of the ATM User-to-User bit 
for the last ATM cell of the PSN frame. Note: The ATM User-to- 
User bit is the least significant bit of the PTI field in the ATM 
header. This field is used to support the fragmentation 
functionality described later in this section. 

E (EFCI) bit 

This field is used to convey the EFCI state of the ATM cells. 
The EFCI state is indicated in the middle bit of each ATM cell's 
PTI field. 


ATM-to-PSN direction (ingress): The EFCI field of the control 
byte is set to the EFCI state of the last cell of the AAL5 PDU or 
AAL5 fragment. 


PSN-to-ATM direction (egress): The EFCI state of all constituent 
cells of the AAL5 PDU or AAL5 fragment is set to the value of the 
EFCI field in the control byte. 
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* C (CLP) bit 


This field is used to convey the cell loss priority of the ATM 
cells. 


ATM-to-PSN direction (ingress): The CLP field of the control byte 
is set to 1 if any of the constituent cells of the AAL5 PDU or 
AAL5 fragment has its CLP bit set to 1; otherwise, this field is 
set to 0. 


PSN-to-ATM direction (egress): The CLP bit of all constituent 
cells for an AAL5 PDU or AAL5 fragment is set to the value of the 
CLP field in the control byte. The payload consists of the 
re-assembled AAL5 CPCS-PDU, including the AAL5 padding and 
trailer or the AAL5 fragment. 


11.2.  Fragmentation 
The ingress PE may not always be able to reassemble a full AAL5 
frame. This may be because the AAL5 PDU exceeds the pseudowire MTU 
or because OAM cells arrive during reassembly of the AAL5 PDU. In 
these cases, the AAL5 PDU shall be fragmented. In addition, 
fragmentation may be desirable to bound ATM cell delay. 


When fragmentation occurs, the procedures described in the following 
subsections shall be followed. 


11.2.1. Procedures in the ATM-to-PSN Direction 
The following procedures shall apply while fragmenting AAL5 PDUs: 


- Fragmentation shall always occur at cell boundaries within the 
AAL5 PDU. 


- Set the UU bit to the value of the ATM User-to-User bit in the 
cell header of the most recently received ATM cell. 


- The E and C bits of the fragment shall be set as defined in 
section 9. 


- If the arriving cell is an OAM or an RM cell, send the current 


PSN frame and then send the OAM or RM cell using One-to-one 
single cell encapsulation (VCC). 
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T2: 


2.2. Procedures in the PSN-to-ATM Direction 
The following procedures shall apply: 


- The 3-bit PTI field of each ATM cell header is constructed as 
follows: 


-i. The most significant bit is set to 0, indicating a user data 
cell. 


-ii. The middle bit is set to the E bit value of the fragment. 


-iii. The least significant bit for the last ATM cell in the PSN 
frame is set to the value of the UU bit of Figure 12. 


-iv. The least significant PTI bit is set to 0 for all other 
cells in the PSN frame. 


- The CLP bit of each ATM cell header is set to the value of the C 
bit of the control byte in Figure 12. 


- When a fragment is received, each constituent ATM cell is sent in 
correct order. 


Mapping of ATM and PSN Classes of Service 


This section is provided for informational purposes, and for guidance 
only. This section should not be considered part of the standard 
proposed in this document. 


When ATM PW service is configured over a PSN, the ATM service 
category of a connection SHOULD be mapped to a compatible class of 
service in the PSN network. A compatible class of service maintains 
the integrity of the service end to end. For example, the CBR 
service category SHOULD be mapped to a class of service with 
stringent loss and delay objectives. If the PSN implements the IP 
Diffserv framework, a class of service based on the EF PHB is a good 
candidate. 


Furthermore, ATM service categories have support for multiple 
conformance definitions [TM4.0]. Some are CLP blind (e.g., CBR), 
meaning that the QoS objectives apply to the aggregate CLPO+1 
conforming cell flow. Some are CLP significant (e.g., VBR.3), 
meaning that the QoS objectives apply to the CLPO conforming cell 
flow only. 


When the PSN is MPLS based, a mapping between the CLP bit and the EXP 
field can be performed to provide visibility of the cell loss 
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priority in the MPLS network. The actual value to be marked in the 
EXP field depends on the ATM service category, the ATM conformance 
definition, and the type of tunnel LSP used (E-LSP or L-LSP). The 
details of this mapping are outside the scope of this document. 
Operators have the flexibility to design a specific mapping that 
satisfies their own requirements. 


In both the ATM-to-PSN and PSN-to-ATM directions, the method used to 
transfer the CLP and EFCI information of the individual cells into 
the ATM-specific field, or flags, of the PW packet is described in 
detail in sections 6 through 9 for each encapsulation mode. 


13. ILMI Support 


An MPLS edge PE MAY provide an ATM Integrated Local Management 
Interface (ILMI) to the ATM edge switch. If an ingress PE receives 
an ILMI message indicating that the ATM edge switch has deleted a VC, 
or if the physical interface goes down, it MUST send a PW status 
notification message for all PWs associated with the failure. When a 
PW label mapping is withdrawn, or PW status notification message is 
received, the egress PE MUST notify its client of this failure by 
deleting the VC using ILMI. 


14. ATM-Specific Interface Parameter Sub-TLVs 


The Interface parameter TLV is defined in [RFC4447], and the IANA 
registry with initial values for interface parameter sub-TLV types is 
defined in [RFC4446], but the ATM PW-specific interface parameter is 
specified as follows: 


— 0x02 Maximum Number of concatenated ATM cells. 


A 2-octet value specifying the maximum number of concatenated ATM 
cells that can be processed as a single PDU by the egress PE. An 
ingress PE transmitting concatenated cells on this PW can 
concatenate a number of cells up to the value of this parameter, 
but MUST NOT exceed it. This parameter is applicable only to PW 
types 3, 9, 0x0a, Oxc, [RFC4446], and Oxd and is REQUIRED for 
these PWC types. This parameter does not need to match in both 
directions of a specific PW. 


15. Congestion Control 


As explained in [RFC3985], the PSN carrying the PW may be subject to 
congestion, with congestion characteristics depending on PSN type, 
network architecture, configuration, and loading. During congestion 
the PSN may exhibit packet loss that will impact the service carried 
by the ATM PW. In addition, since ATM PWs carry a variety of 
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services across the PSN, including but not restricted to TCP/IP, they 
may or may not behave in a TCP-friendly manner prescribed by 
[RFC2914]. In the presence of services that reduce transmission 
rate, ATM PWs may thus consume more than their fair share and in that 
case SHOULD be halted. 


Whenever possible, ATM PWs should be run over traffic-engineered PSNs 
providing bandwidth allocation and admission control mechanisms. 
IntServ-enabled domains providing the Guaranteed Service (GS) or 
Diffserv-enabled domains using EF (expedited forwarding) are examples 
of traffic-engineered PSNs. Such PSNs will minimize loss and delay 
while providing some degree of isolation of the ATM PW's effects from 
neighboring streams. 


It should be noted that when transporting ATM, Diffserv-enabled 
domains may use AF (Assured Forwarding) and/or DF (Default 
Forwarding) instead of EF, in order to place less burden on the 
network and gain additional statistical multiplexing advantage. In 
particular, Table 1 of Appendix "V" in [ATM-MPLS] contains a detailed 
mapping between ATM classes and Diffserv classes. 


The PEs SHOULD monitor for congestion (by using explicit congestion 
notification, [VCCV], or by measuring packet loss) in order to ensure 
that the service using the ATM PW may be maintained. When a PE 
detects significant congestion while receiving the PW PDUs, the PE 
MAY use RM cells for ABR connections to notify the remote PE. 


If the PW has been set up using the protocol defined in [RFC4447], 
then procedures specified in [RFC4447] for status notification can be 
used to disable packet transmission on the ingress PE from the egress 
PE. The PW may be restarted by manual intervention, or by automatic 
means after an appropriate waiting time. 


Security Considerations 


This document specifies only encapsulations, not the protocols used 
to carry the encapsulated packets across the PSN. Each such protocol 
may have its own set of security issues [RFC4447][RFC3985], but those 
issues are not affected by the encapsulations specified herein. Note 
that the security of the transported ATM service will only be as good 
as the security of the PSN. This level of security might be less 
rigorous than a native ATM service. 
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